home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
NetNews Offline 2
/
NetNews Offline Volume 2.iso
/
news
/
comp
/
std
/
c
/
639
< prev
next >
Wrap
Internet Message Format
|
1996-08-06
|
2KB
Path: news.iadfw.net!usenet
From: Larry Weiss <lfw@iadfw.net>
Newsgroups: comp.std.c
Subject: Re: externsions and Standard C
Date: Sat, 23 Mar 1996 16:31:20 -0600
Organization: customer of Internet America
Message-ID: <31547BB8.31D7@iadfw.net>
References: <4gum82$14v4@info4.rus.uni-stuttgart.de> <MPLANET.31530e9djcoffin98993e@news.rmii.com> <31536199.219868914@nntp.ix.netcom.com> <315418FA.1508@iadfw.net> <1996Mar23.202452.14793@sq.com>
NNTP-Posting-Host: dal20-22.ppp.iadfw.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (Win16; I)
Mark Brader wrote:
>
> lfw@iadfw.net writes:
> > Mike Rubenstein wrote:
> > > You've missed a rather subtle point. Such extensions are legal but
> > > they do not introduce integer types. The standard defines the signed
> > > integer types as being signed char, short int, int, and long int (and
> > > similarly for unsigned integer types).
>
> > It must be pretty subtle!
>
> Not at all.
>
> > Can you cite specific Clause references ...
>
> It's in 6.1.2.5/3.1.2.5:
>
> # There are four "signed integer types", designated as signed char,
> # short int, int, and long int ...
>
> It says four, not four or more.
>
> # For each of the signed integer types, there is a corresponding
> # (but different) "unsigned integer type".
>
> It is true that size_t is specified by 6.3.3.4/3.3.3.4 as having an
> "unsigned integral type" rather than "unsigned integer type", but the
> draft Record of Reponse 2 confirms that these terms were not intended
> to be distinguished.
>
> Thus if x is of type size_t, printf ("%ul\n", (unsigned long) x); is
> safe under the present standard.
> --
Let me try one more time to understand what makes an extension "legal"
and what makes an extension "impossible".
Am I correct to understand that it is impossible for an implementation
to define an extension that introduces new integer types? (I'm pretty sure
answer if "yes" for the above stated reasons).
Am I correct to understand that is is possible for an implementation to
define an extension that introduces a new type named verylong that
behaves very much like, yet is not, an integer type? If so, what clause
of the Standard makes that extension possible?
(Let's get that much understood before I go off and study this some).